【レポート】AWS Webinar – Amazon Redshift: データ移行とデータロードに関するベストプラクティス

しんや

2015.07.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

日本時間2015年07月23日の午前1時(Wednesday 22 July 2015, 09:00 AM - 10:00 AM / Time Zone: (GMT-08:00) Pacific Time (US and Canada))に、AWSのWebinarで『Best Practices: Amazon Redshift Migration and Loading Data』というタイトルのセッションが行われていたので少し夜更かしして聞いてみました。タイトルが示す通り、Amazon Redshiftに於けるデータ移行・データのロードに関する部分のベスト・プラクティスをまとめた内容でしたが、これまでの情報整理も兼ねてとても参考になるものが多かったので当エントリではその内容をざっくりまとめた形でレポートしてみたいと思います。

データロードについて：データロードのユースケース
- 空のRedshiftデータベースへのロード
- 元システムで検知した変更をRedshiftへロード
TRUNCATEとロード：これまでで最も簡単な選択肢。
- データをS3に移動...multi-partアップロード/import/exportサービス/Direct Connect
- テーブル単位でデータをRedshiftにCOPY
変更をロード
- 元システムの変更を検知・識別。データをS3に移動し、変更をロード。
- 方法(1).Upsertプロセスを使って変更をロードする
- 方法(2).Partner ETLツールを使って変更をロードする(※参照：パートナー - Amazon Redshift（クラウドデータウェアハウスソリューション） | アマゾンウェブサービス（AWS 日本語）)
UPSERT
- Redshiftに於いて新しい行を追加し、行の変更を更新。 (※参照：新しいデータの更新と挿入 - Amazon Redshift)

Amazon Redshiftアーキテクチャに関する説明：下記画像を参照。

COPYコマンド

空のテーブルにデータをCOPYする際はCOMPUPDATEオプションを"ON"に。 (※参照：自動圧縮ありでテーブルをロードする - Amazon Redshift)
スライスそれぞれが一度に1つのファイルをロードする事が可能。
入力ファイルを分割しよう。そうする事で全てのスライスが並行してデータをロード出来る。
1ファイルだと処理するスライスは1つしか無いのでスループットの向上は見込めないが、スライス数に合う形でファイルを分割しておくとそれぞれのスライスがファイルのCOPYを並行して行う事が出来、スループットを最大化出来る。
Manifestファイルを使う。(※参照：マニフェストを使用し、データファイルを指定する - Amazon Redshift)
- 何がロードされ、入力ファイルが無かった時にどういう対応方法を取るかを正確に制御する為に、Manifestファイルを使おう。JSONマニフェストファイルをS3に配置し、クラスタにあなたの望むものを正確にロードさせるようにする。
プライマリーキー
- Amazon Redshiftは主キー制約を強制しない。もしデータを2回ロードした場合、Redshiftではそのまま重複登録されてしまう。
- DMLで主キーを宣言した場合、オプティマイザはそのデータがユニークである事を期待する。

ロード毎にsort/distkeyカラムをANALYZE
- Amazon Redshiftのクエリオプティマイザは最新の統計情報に依存している。
- ロード毎に統計情報を更新する事でパフォーマンスを最適化すべし。

自動圧縮
- 低コストでより良いパフォーマンスが見込める。
- 空のテーブルにロードする際、COPYコマンドはデータを自動的にサンプリングする。デフォルトは対象100000件。
- もしETLプロセスを普段から実践しており、一時テーブル・ステージングテーブルなどを使っている場合、自動圧縮はoffに。
- 適切なエンコーディングを決定する為に、ANALYZE COMPRESSIONを使う。得たエンコーディング情報はDMLに反映。

STL_LOAD_COMMITSテーブルの確認
- ロード操作が完了したら、STL_LOAD_COMMITSシステムテーブルを参照し、期待したファイルがロードされているかどうかを確認。
- 参照：STL_LOAD_COMMITS - Amazon Redshift
- 参照：データが正しくロードされたことを確認する - Amazon Redshift

COPYコマンドベスト・プラクティス：
- データ投入にINSERTで1行ずつ...は避けるべし。COPYを使おう。INSERTはパラレル実行出来ない。
- もしデータを他のテーブルに移動する場合、ディープコピーを使う。 (※参照：ディープコピーを実行する - Amazon Redshift)

自動化のオプション

多くの顧客がRedshiftへデータを投入するためにスクリプトをEC2インスタンス上で実行している。
他のオプションとしては、Amazon Data Pipelineを使うという手もある。
また、AWS Lambda-based Amazon Redshift Loaderというのもある。

Lambda based Redshift Loaderを使う

(ほぼ)リアルタイムローディング

("Near Real-time loading"のNearを『ほぼ』って訳してみたけどニュアンス的には合ってるのかな...?)

マイクロバッチローディング
- 時系列データに対して理想的な手法。
- カラムエンコーディングは事前に設定済
- 統計情報計算の頻度を減らす
- ソートキーの順序でロードする
- SSDインスタンスを使う
- 'Load Stream'アーキテクチャを使って開発する事を検討
- 参考リンクは『参考リンク』のセクションにて。